XP (eXtreme Programming)
第 4 章 價値
4.1 communication
team による software 開發で最も重要なのは、communication である。開發中に問題が發生したときには、すでに誰かが解決策を知ってゐることが多い。だが、その情報は變更する權限のある人には傳はらない。情報があるのに傳はらないのは、自分の直感を無視するときの心の內面と同じだ。他人と communication する必要があるときには、その影響の度合いはさらに惡化する。
「情報があるのに傳はらないのは、自分の直感を無視するときの心の內面と同じだ。」
4.2 simplicity
私は「最も simple で、うまくいきさうなものは何ですか?」と質問するやうにしてゐる。批判する人たちは、質問の後半部分を見逃してゐるやうだ。「我々には深刻な security や信賴性といった制約がありますので、system を simple にはできません」などと返ってくる。私は、simple すぎてうまくいかないものについて質問しているわけではない。ムダな複雜性を排除するために、何ができるかを考へてもらってゐるのだ。
communication によって、現狀の觀點からは必要がない、あるいは時閒的猶豫 (←→餘裕)のある要件を削除すれば、それが simplicity の達成につながる。simplicity を達成すれば、必要な communication も少なくなる。 4.3 feedback
feedback は communication に缺かせない。「performance は問題になるかな?」「わからないね。performance 測定用の prototype を作って確認してみよう」。feedback は simplicity にも影響する。3 つの解決策のなかで、どれが最もsimple になるだらうか? そんなときは、3 つすべてを試して確認してみよう。同じものを 3 囘實裝するのはムダに思へるかもしれない。だが、simplicity が備はった納得できる解決策にたどり着くには、かうするのが最も效率的な方法だらう。それと同時に、system が simple になれば、その分だけ feedback を受け取ることも簡單になる。
4.4 勇氣 (courage)
勇氣のみでは危險だが、他の價値と合はせれば強力だ。勇氣を持って眞實を語れば (たとへそれが不愉快なことであっても)、communication や信賴が強化されていく。うまくいかない解決策を捨てて、勇氣を持って新しい解決策を見つければ、simplicity が促進される。勇氣を持って現實の具體的な答へを求めれば、そこから feedback が生まれる。
4.5 respect
software 開發に關係してゐる人は、人閒として等しく重要である。他の人よりも本質的に重要な人などゐるはずがない。software 開發において人閒性と生產性を同時に高めるには、team に對する個人の貢献を respect する必要がある。私も重要であり、あなたも重要だ。
第 5 章 原則
5.1 人閒性 (humanity)
5.2 經濟性 (economics)
5.3 相互利益 (mutual benefit)
5.4 自己相似性 (self-similarity)
5.5 改善 (improvement)
5.6 多樣性 (diversity)
5.7 ふりかへり (reflection)
5.8 流れ (flow)
流れ作業 ($ \ne流し作業)
5.9 機會 (opportunity)
5.10 冗長性 (redundancy)
5.11 失敗 (failure)
5.12 品質 (quality)
5.13 baby steps
5.14 責任の引き受け (accepted responsibility)
第 7 章 主要 practice
7.1 全員同席 (sit together)
7.2 team 全體 (whole team)
そのためには、以下のやうな「team」感が必要だ。
我々は、歸屬してゐる。
我々は、一緒の仲閒である。
我々は、お互ひに仕事、成長、學習を支へ合ってゐる。
7.3 情報滿載の workspace (informative workspace)
課題を解決できたり、chart の更新が滯ってゐたりすれば、すぐに外してしまおう。その space は重要な現在進行形の情報のために使ひたい。
かんばん board
7.4 いきいきとした仕事 (energized work)
7.6 stories
user story
user story mapping
event storming
7.7 週次 cycle (weekly cycle)
7.8 四半期 cycle (quarterly cycle)
四半期の計劃では、以下のことを行う。
bottleneck を特定する (特に team の外側で制御されてゐるもの)。
修正作業に着手する。
四半期の theme を計畫する。
「theme」を「story」と區別してゐるのは、team が全體像と今週の story の調和を考えずに、今やってゐることだけに集中する傾向があるからだ。theme は marketing の loadmap を描くやうな規模の大きな計劃にも適している。
dual track agile
theme に取り組むための四半期分の story を選擇する。
project を組織に適合させる全體像に集中する。
技術的 spike
survival mode から拔け出す
7.10 10 分 build (ten-minute build)
7.11 繼續的 integration (continuous integration; CI)
7.12 test-first programming
7.13 incremental な設計 (incremental design)
第 9 章 導出 practice
9.1 本物の顧客參加 (real customer involvement)
9.2 incremental な deploy (incremental deployment)
9.3 team の繼續 (team continuity)
9.4 team の縮小 (shrinking teams)
9.5 根本原因分析 (root-cause analysis)
9.6 code の共有 (shared code)
9.7 code と test (code and tests)
9.8 單一の code base (single code base)
9.9 daily deployment
9.10 交涉による scope 契約 (negotiated scope contract)
9.11 利用都度課金 (pay-per-use)